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ABSTRACT 


ADA-like  language  is  proposed  as  a  high  level,  specification 
oriented  modeling  tool.  It  is  asserted  that  the  very  early  system  design 
modeling  tasks  are  typically  not  given  adequate  stress,  with  the  result 
that  poor  system  designs  are  carried  forward  into  the  mid  design  phases. 

A  lack  of  suitable  modeling  tools  is  likely  one  reason,  and  so  an  ADA-like 
modeling  technique  is  proposed.  It  has  many  of  the  properties  of  speci¬ 
fication  languages,  including  the  ability  to  be  machine  processed  to  indi¬ 
cate  incomplete  or  inconsi  4jnt  systems.  The  unclassified  portions  of  the 
SPY-1  radar  component  of  the  AEGIS  weapon  system  is  used  as  a  test  vechicle 
to  illustrate  the  modeling  technique.^^ 
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I  Purpose  of  the  Research 


This  research  evaluates  the  use  of  the  new  DoD  programming 
language  ADA  [Ichbiah79,  Wegner801  (or  an  ADA-like  language)  as  a 
modeling  technique  for  large  scale  multiprocessing  computer  sys¬ 
tems.  In  particular,  the  research  is  to  evaluate  the  effective¬ 
ness  of  such  a  modeling  technique  vis-a-vis  other,  more  conven¬ 
tional  techniques  such  as  flowcharts,  block  diagrams,  and  narra¬ 
tives.  The  measure  of  effectiveness  is  a  qualitative  assessment 
of  its  ease  of  use  and  understandibility  by  designers  and  "custo¬ 
mers’'  (the  purchasers  of  the  modelled  system). 


II  Background 


The  ADA  language  is  currently  undergoing  final  definition  as 
the  new  standard  DoD  embedded  systems  language.  ADA,  when 
adopted,  will  be  the  standard  language  for  programming  computers 
that  are  components  in  weapon  systems.  The  language  incorporates 
the  latest  concepts  in  algorithmic  language  design,  including 
modern  control  structures,  user-defined  data  types,  and  the  abil¬ 
ity  to  coordinate  concurrently  executing  "tasks".  As  of  this 
writing  no  production  ADA  compiler  exists,  and  so  the  ADA  pro¬ 
grams  included  in  this  report  have  not  been  verified  as  beinq 
syntactically  or  semantically  correct. 

A  major  problem  with  all  large  scale  systems  (multiprocessing 
systems  like  AEGIS  in  particular)  is  the  early  design  phase  in 
which  customer  requirements  are  specified.  Typically  system 
development  is  retarded  and  budgets  exceeded  because  the  system 


is  incompletely  or  incorrectly  specified. 


One  reason  a  system  may  become  incompletely  or  incorrectly 
soecified  is  the  lack  of  sufficient  communication  between  the 
designers  of  the  system  (technical  persons)  and  the  buyer  or  cus¬ 
tomer  of  the  system  (the  persons  with  the  problem  the  system  is 
meant  to  resolve).  Due  to  their  different  knowledge  of  the  prob¬ 
lem  these  two  groups  have  a  different  perception  and  understand¬ 
ing  of  the  problem,  and  yet  the  design  of  a  successful  system 
largely  depends  upon  how  closely  the  perceptions  can  be  brought 
together.  Unfortunately,  because  of  these  misperceptions,  the 
designers  proceed  with  a  system  that  satisfies  the  problem  as 
they  understand  it,  and  the  customer  is  unaware  of  this  because 
of  the  lack  of  communication.  At  some  point  the  difference  is 
discovered,  but  usually  after  much  effort  has  been  wasted.  Better 
communication  is  a  solution  to  this  problem,  and  a  candidate 
mechanism  for  this  purpose  is  a  modelinq  technique  more  under¬ 
standable  by  both  the  designers  and  the  customers.  Computer  sci¬ 
ence  specialists,  known  as  software  engineers,  have  been  and  are 
developing  tools  to  deal  with  this  problem  [Teich77,  Davis79, 
Jones791 .  Collectively  these  tools  are  called  "specification 
languages",  and  are  usually  interactive  programming-like 
languages  that  can  be  computer  processed  to  indicate  specifica¬ 
tion  related  problems. 

It  is  asserted  here  that  ADA  (or  an  ADA-like  lanquage)  can  be 
used  as  a  specification  tool.  This  results  from  the  ability  of 
ADA  to  allow  top-down  proqram  development,  in  which  functionality 
can  be  omitted  at  a  high  level,  only  to  be  incorporated  at  a 


later  time.  In  addition,  ADA  incorporates  control  structures  for 
multitasking,  in  which  concurrently  executing  tasks  are  coordi¬ 
nated  in  a  specified  way.  Information  may  be  passed  among  the 
tasks  in  a  manner  which  is  independant  of  the  underlying  computer 
architecture  (shared  memory  or  distributed  processing).  If  ADA 
proves  useful  in  this  role  the  conversion  of  the  specifications 
into  executable  code  would  be  less  costly  and  quicker  than  other¬ 
wise  possible,  a  worthwhile  objective. 

Other  commonly  used  programming  languages,  such  as  PL/I,  For¬ 
tran,  or  CMS— 2 ,  could  also  be  a  basis  of  a  modeling  tool.  However 
ADA  has  most  of  the  qood  features  of  those  languages  and  some 
additional  features  as  well.  This  is  not  unexpected  as  ADA  is 
meant  to  be  a  contemporary  refinement  of  all  that  is  known  about 
programming  languages.  For  example  ADA's  multitasking  capability 
is  a  more  modern  mechanism  than  the  equivalent  in  PL/I.  Thus  ADA 
aopears  to  be  the  best  notation  upon  which  to  build  a  high  level 
modeling  tool. 

In  the  remaining  sections  of  this  report  the  derivation  of  an 
ADA-like  model  of  SPY-1  is  accomplished.  The  narrative  accompany¬ 
ing  the  derivation  is  meant  to  exhibit  the  derivation  thought 
process,  and  assumes  at  least  some  familiarity  with  contemporary 
programming  language  practices  and  concepts. 

Ill  The  Research  Vehicle 

The  SPY-1  radar  component  of  the  AEGIS  weapon  system  is 
chosen  as  a  research  vehicle  for  several  reasons.  First,  it  is  an 
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ongoing  research  project  at  the  Naval  Postgraduate  School,  where 
three  faculty  members  and  several  graduate  students  are  investi¬ 
gating  a  microprocessor  based  multiprocessing  implementation  of 
SPY-1.  Secondly  another  faculty  member  (the  author)  has  the 
requisite  knowledge  of  ADA  and  is  interested  in  the  research 
topic.  Fortunately  enough  unclassified  documentation  of  SPY-1 
exists  for  meaningful  research  to  be  carried  out.  Finally  the 
project  is  small  enough  to  allow  current  funding  to  be  used. 

The  source  of  information  for  the  research  is  almost  entirely 
from  a  classified  report  [WS-105441  with  all  the  classified  pages 
removed.  The  omitted  information  results  in  some  gaps  in  the 
study,  but  not  enough  to  affect  the  modeling  effort.  In  the 
remaining  sections  this  document  is  referred  to  as  the  "refer¬ 
enced  document”  or  "referenced  source". 

In  the  next  section  an  overall  summary  of  the  SPY-1  radar 
system  and  its  interface  with  other  AEGIS  components  is 
presented. 

IV  The  SPY-1  Radar 

This  section  describes  the  SPY-1  radar  system  at  the  highest 
level.  The  information  is  derived  from  the  document  referenced 
above,  consisting  mostly  of  a  narrative  with  accompanying  tables 
and  diagrams. 

At  the  highest  level  the  SPY-1  interfaces  with  other  AEGIS 
components,  namely  a  Command  and  Control  System,  a  Weapons  Con¬ 
trol  System,  an  Operational  Readiness  Test  System,  a  Missile 
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Oatalink  System,  and  a  Gun  Fire  Control  System.  Interfaces  are 
defined  to  these  components  in  the  form  of  data  structures;  in 
some  cases  the  details  are  classified.  In  addition  an  interface 
with  the  AEGIS  Tactical  Executive  System  is  maintained.  Listing 
1  shows  how  ADA  might  be  used  to  describe  this  level  of  detail. 
PACKAGE  spy_l  IS 

USE  interface_types_package;  —  global  messages 
PROCEDURE  c&d_interface  (  parameters  ); 

PROCEDURE  wcs_inter f ace  (  parameters  ); 

PROCEDURE  orts_interface  (  parameters  );  —  classified 

PROCEDURE  gfcs_interface  (  parameters  );  —  classified 

PROCEDURE  ates_interface  (  parameters  );  —  classified 

PRIVATE 

—  declaration  of  all  private  data  types 

—  and  private  data  objects,  not  important 

—  at  this  point  in  the  modeling  effort 
END  spy_l; 


Listing  1.  An  ADA  package  specification  for  SPY-1. 

The  reader  is  reminded  that  the  ADA-like  model  derived  in  the 
following  paragraphs  only  represents  a  loqical  explanation  of  the 
SPY-1  radar  system,  and  that  no  particular  underlying  computer 
architecture  need  be  assumed.  Thus  it  is  not  meaningful  (at  this 
stage  of  modeling)  to  think  of  procedures  or  tasks  as  being 
dynamically  loaded,  etc.;  the  essential  point  is  that  they  are 
invoked  when  needed  and  execute  according  to  the  ADA  language 
semantics. 

Before  discussing  this  ADA-like  code,  the  notion  of  a  "pack¬ 
age"  is  defined.  In  ADA  a  package  is  a  means  of  grouping  related 
items  together,  typically  data  object  declarations  and  subprogram 
declarations.  A  package  is  referred  to,  within  the  code  of  some 
other  programming  unit,  by  means  of  a  USE  statement  that  effec¬ 
tively  inserts  the  "packaged"  statements.  Thus  a  package  is  not 


directly  executable,  but  rather  contains  executable  units  (pro¬ 
cedures  and/or  tasks)  that  may  be  invoked  from  outside  the  pack¬ 
age.  It  may,  however,  have  an  executable  initialization  com¬ 
ponent.  A  package  may  be  divided  into  two  parts,  a  "specifica¬ 
tion"  part  that  is  "visible"  to  the  external  environment,  and  a 
"body"  which  is  hidden  from  the  external  environment.  Thus  the 
"user"  of  the  package  can  only  access  the  material  exhibited  in 
the  specification  part. 

The  code  shown  is  not  exactly  ADA;  the  word  "parameters" 
would  have  to  be  replaced  by  the  actual  data  objects  being 
passed.  Double  dashes  indicate  the  start  of  comments  that  con¬ 
tinue  until  the  end  of  the  line.  Not  shown  (because  it  is  not 
relevant  at  this  time)  is  the  declaration  of  private  data  types 
and  objects;  such  types  and  data  objects  would  be  known  to  the 
users  of  the  SPY-1  package  but  their  underlying  structural  com¬ 
ponents  would  not  be  accessible.  The  definition  of  the  various 
procedures  will  be  shown  elsewhere. 

How  is  the  SPY-1  package  used  in  a  real  ADA  programming 
environment?  It  would  be  embedded  in  another  "AEGIS  package" , 
where  it  :ld  be  one  of  several  packages,  along  with  other  code. 
This  is  beyond  the  scope  of  the  research  project  and  so  is  not 
pursued  further,  except  to  point  out  the  various  procedures  would 
be  invoked  from  within  the  encompassing  AEGIS  package. 

The  details  of  the  messages  that  can  be  sent  and  received  via 
the  procedures  and  the  corresponding  procedure  bodies  are 
described  in  a  corresponding  package  "body",  as  is  shown  in  List¬ 
ing  2.  This  is  a  companion  component  the  specification 
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package  shown  in  Listing  1;  together  they  will  completely  define 
the  SPY-1  package. 


PACKAGE  BODY  spy_l  IS 

—  Local  type  and  object  declarations  and 

—  definitions  of  the  five  procedures  whose 

—  headers  are  in  the  package  specification 

—  shown  in  Listing  1.  These  would,  in  turn, 

—  call  entry  points  in  the  task  immediately 

—  following. 

PROCEDURE  orts_inter f ace  (...)  IS 

...  —  invoked  from  an  ORTS  task 

BEGIN 
•  •  • 

initialization_command;  —  invokes  the 
—  spy_l_control  task 

•  •  • 

END  orts_interf ace ; 

TASK  spy_l_control  IS 

—  procedure  and  entry  declarations,  etc. 

TYPE  ...  —  message  type  declarations 

ENTRY  initializationcommand; 

ENTRY  task_command;  —  other  entries  symbolically 
END  spy_l_control ; 

TASK  BODY  spylcontrol  IS 

—  local  declarations 
BEGIN 

ACCEPT  initialization_command;  —  from  the 

—  ORTS  interface  procedure  shown  above. 

LOOP 

SELECT 

ACCEPT  task_command ;  —  others 
•  •  • 

END  SELECT; 

END  LOOP; 

END  spy_l_control; 

BEGIN  —  initialization  part 

INITIATE  spy_l_contr ol ;  —  starts  this  task 

END  spy_l; 


Listing  2.  ADA  representation  of  SPY-1  package  body. 

The  program  shown  in  Listing  2  is  a  very  high  level  represen¬ 
tation  of  the  overall  SPY-1  system,  and  so  is  described  in  some 
detail  in  the  following  paragraphs.  Note  that  within  the  SPY-1 
package  body  the  executable  portion  consists  of  at  least  one 
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statement  (between  the  package  body  BEGIN  and  END  delimiters), 
namely  "INITIATE  spy_l_control " .  In  the  declarative  portion  of 
the  package  body  is  defined  the  "spy_l_controi"  task  that  is 
started  by  the  initiate  command.  This  task  will  control  the 
overall  execution  of  the  SPY-1  system,  doing  most  of  what  the 
"ates"  component  would  do  in  the  current  SPY-1  system.  By  defini¬ 
tion  a  task  is  a  procedure  that  executes  in  parallel  with  other 
procedures.  They  can  be  initiated  (started)  or  aborted  (stopped) , 
and  can  be  made  to  coordinate  their  activities  with  other  pro¬ 
cedures  . 

Thus  a  controlling  task  is  started  from  the  SPY-1  package 
body,  and  so  execution  of  the  task  body  also  shown  in  Listing  2 
is  initiated.  The  first  statement  within  the  task  body  is  an 
"ACCEPT  initialization_command"  statement.  An  ACCEPT  statement 
forces  a  "rendezvous"  with  another  task  or  procedure  that  is  exe¬ 
cuting  a  corresponding  "call"  statement.  The  label 
"initialization_command”  is  an  entry  point  in  the  spyl  control 
task,  and  is  called  from  one  (or  more)  of  the  procedures  speci¬ 
fied  in  Listing  1.  As  shown  in  Listing  2  the  entry  point  is 
called  indirectly  from  a  task  in  ORTS  (Operational  Readiness  Test 
System,  another  component  of  the  AEGIS  system) .  Until  the  ren¬ 
dezvous  is  accomplished  the  calling  procedure  is  halted;  in  this 
case  the  spy_l_control  task  tests  for  an  appropriate  initializa¬ 
tion  command  (indirectly  received  from  ORTS);  it  does  not  proceed 
until  the  command  arrives.  In  the  example  shown  no  messages  (in 
the  form  of  a  parameter  list)  are  passed  between  calling  and 
called  tasks;  this  additional  detail  will  be  added  later. 
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When  the  initialization  command  is  received  the  rendezvous  is 
said  to  have  occured,  and  after  some  processing  in  the 
spy_l_control  task  both  the  calling  and  called  tasks  or  pro¬ 
cedures  are  allowed  to  proceed  independently  of  each  other.  As 
shown  in  Listing  2,  this  results  in  the  entering  of  an  infinite 
loop  (LOOP  -  END  LOOP  statements).  It  is  not  really  an  infin¬ 
ite  loop  because  the  loop  body  contains  other  ACCEPT  statements, 
shown  symbolically  by  the  "ACCEPT  task_command"  statement.  In 
this  manner  other  SPY-1  tasks  are  initialized,  coordinated,  and 
aborted.  These  other  tasks  are  discussed  in  a  following  section. 

V  The  Rendezvous  Concept 

It  is  important  that  the  rendezvous  concept  be  fully  under¬ 
stood  before  proceeding.  Consider  two  programs  (modeling  some 
procedures)  that  require  interaction  to  accomplish  some  common 
goal.  Typically  one  program  may  want  to  invoke  the  other  program 
to  carry  out  some  specific  job  on  its  behalf. 

Several  mechanisms  for  accomplishing  this  interaction  have 
been  devised.  ADA  adopts  a  "rendezvous"  concept,  in  which  a  cal¬ 
ling  program  must  know  something  about  the  program  it  wishes  to 
invoke,  but  in  which  the  called  program  need  not  know  anything 
about  the  calling  program.  Thus  the  mechanism  is  one  sided  in 
that  sense.  This  is  clearly  superior  to  a  symmetrical  situation 
where  both  parties  to  the  interaction  must  know  of  each  other; 
the  rendezvous  concept  allows  a  library  of  programs  to  exist  and 
be  called  as  needed,  whereas  the  symmetrical  mechanism  does  not. 
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Consider  the  situation  in  which  a  data  structure  represents 
some  entity  that  must  undergo  certain  processing  during  its 
existence.  In  a  grocery  store  context  a  customer  may  require  the 
services  of  a  checkout  stand,  for  example.  Here  the  customer  must 
enter  a  queue  (possibly  empty)  to  await  his  turn  for  service. 
While  waiting  the  customer  is  necessarily  idle,  in  the  sense  he 
can  not  do  additional  shopping  or  anything  else.  When  prior  cus¬ 
tomers  have  been  serviced  the  particular  customer  may  be  pro¬ 
cessed  (a  modification  of  the  data  structure)  and  then  released 
to  some  other  environment.  In  the  modeling  technique  used  here  we 
say  a  customer  attempts  a  rendezvous  with  the  server;  if  the 
server  is  not  available  then  the  calling  entity  must  wait. 

The  rendezvous  technique  provides  additional  mechanisms 
allowing  priority  queues,  pre-emption,  and  availability  of  a  set 
of  resources  to  determine  service  response.  None  of  these  is  dis¬ 
cussed  in  this  report.  However  the  rendezvous  concept  allows 
classical  problems  such  as  the  consumer-producer,  reader-writer, 
dining  philosophers,  etc.  to  be  modelled  in  a  stra ightfoward 
manner . 

Again  the  reader  is  reminded  that  nothinq  in  the  notation 
dictates  anything  about  the  underlying  implementation  of  the 
model  on  a  real  set  of  computers.  Thus  it  is  not  meaningful  to 
consider  (at  this  stage)  when  or  how  programs  are  executed;  they 
are  just  executed  according  to  the  semantics  of  the  ADA-like 
language. 

VI  The  SPY-1  Control  Task 


In  this  section  the  overall  structure  of  the  SPY-1  radar 
control  mechanism  is  described. 

The  situation  to  this  point  is  as  follows:  within  the  SPY-1 
package  a  "spy_l_control"  task  is  initiated  and  waits  for  an  ini¬ 
tialization  command  from  one  of  the  specified  procedures.  when 
an  initialization  command  arrives  the  controlling  task  resumes 
execution  and  enters  an  infinite  loop  that  contains  a  SELECT 
statement  that  selects  among  any  rendezvous  request  corresponding 
to  the  ACCEPT  statements.  In  this  manner  the  various  component 
tasks  within  the  SPY-1  system  are  initiated,  aborted,  or  coordi¬ 
nated  as  necessary.  The  various  messages  oassed  among  the  tasks 
have  not  yet  been  explicity  shown. 

We  now  address  the  internal  structures  of  the  SPY-1  radar 
system.  It  can  be  thought  of  as  consisting  of  various  tasks, 
executing  in  parallel  but  in  a  coordinated  fashion,  each  sending 
and  receiving  certain  messages.  Most  of  this  message  passing  and 
coordination  is  strictly  from  within  the  SPY-1  system,  but  in 
addition  there  is  the  external  communication  and  coordination 
with  the  other  AEGIS  system  components.  It  is  the  latter  that  is 
of  primary  interest  here;  we  are  most  concerned  in  modeling  the 
interface  of  SPY-1  with  these  other  components,  and  in  particular 
the  loqical  relationships  of  the  interfaces  and  the  internal 
tasks.  Recall  that  it  is  precisely  these  relationships  that  are 
significant  in  the  early  design  stages,  and  that  it  is  a  premise 
of  this  research  project  that  conventional  notations  are  weak  in 
this  regard,  and  that  the  modeling  technique  used  here  would  be 
an  improvement. 


SPY-1  must  interface  with  five  external  AEGIS  components  as 
is  shown  by  Listing  1:  command  and  decision,  weapons  control, 
operational  readiness  and  testing,  gun  fire  control,  and  AEGIS 
tactical  executive  systems.  Each  of  these  interfaces  consists  of 
several  different  message  types.  Each  different  message  type 
requests  some  particular  service  from  the  SPY-1  radar  system. 
One  example  was  already  illustrated  in  the  previous  section  by 
the  initialization  command  indirectly  from  ORTS.  Consider  now  how 
these  messages  might  be  modelled  in  an  ADA-like  notation. 

The  referenced  source  document  indicates  how  the  various 
messages  are  transmitted  through  the  several  interfaces;  here  we 
concentrate  upon  the  unclassified  ones.  For  example  Tables 
3.4.17-1  and  3.4.17-III  in  the  reference  document  indicate  the 
inputs  and  outputs,  respectively,  of  the  command  and  decision 
interface.  Each  of  the  message  types  has  a  description  of  its 
message  content  fields,  scaling  precision,  data  rate,  conditions, 
operator  intervention  requirement,  and  its  destination  or  source; 
these  are  now  modelled  in  an  ADA-like  notation. 

According  to  the  reference  document,  one  of  the  message  con¬ 
tent  fields  is  a  "message  type"  field;  presumably  it  is  this 
field  that  designates  any  particular  message  as  containing  data 
of  a  particular  format.  In  the  modeling  technique  employed  here 
it  is  only  necessary  to  use  the  contents  of  this  field  to  charac¬ 
terize  the  record.  This  can  be  accomplished  by  using  a  record 
structure  of  the  "variant"  type,  in  which  a  particular  value  of  a 
variable  indicates  the  record  structure  that  follows.  In  this 
SPY-1  model  we  choose  to  define  separate  record  types  for  each 
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interface,  and  indeed  for  each  direction  of  data  flow  within  each 
interface.  This  is  done  so  that  the  semantics  of  the  modeling 
notation  can  be  used  to  our  advantage,  namely  the  ability  of 
"strong  type  checking"  to  enforce  only  leqal  sending  and  receiv¬ 
ing  of  messages. 

TYPE  c4d_interface_input  IS 
RECORD 

kind  s  (track_data,  dataack,  burnthrough_rpt , 

track_acc_rei ,  r*adar_status  ,  burnthrough  acc  rei, 
redundanttrack ,  radar_load_status ,  rsc  status, 
radardoctr ine) ;  —  an  enumerated  data  type 

CASE  kind  OP 

WHEN  trackdata  »> 

...  —  various  field  declarations 

WHEN  data  ack  »> 

...  ~  —  varous  field  declarations 


e 

WHEN  radar  doctr ine  *> 

...  " —  various  field  declarations 

END  CASE; 

END  RECORD; 


Listing  3.  A  variant  record  declaration. 

An  example  of  the  variant  record  structure  mechanism  is 
shown  in  Listing  3.  The  record  structure  consists  of  a  field 
indicating  the  kind  of  message  stored  in  the  remaining  part  of 
the  structure,  in  this  situation  depending  upon  the  value  of  the 
variable  "kind";  each  "when  clause"  declares  the  fields  within 
each  message  type  (not  shown  in  Listing  3;  see  the  appendix  for  a 
complete  example).  Similar  record  structures  are  defined  for  the 
command  and  decision  output  messages,  and  for  all  the  other 
interfaces. 

The  record  definition  described  above  is  of  a  type  of  record. 
In  any  particular  procedure  or  task  variables  of  that  type  may  be 
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declared  and  then  manipulated  as  appropriate.  For  example,  in  a 
sending  procedure  the  declaration  of  a  variable  "messaqe"  (by  a 
"message  :  c&d_interface_input"  statement)  might  be  used  to 
define  a  particular  data  structure  in  which  its  component  fields 
can  be  assigned  specific  values.  The  message  could  be  sent  by 
invoking  an  appropriate  procedure: 

c&d_user_services_input  (message  :  OUT  c&d_interfacej_input) ; 

Here  a  procedure  or  task  entry  name  is  written  followed  by  its 
output  argument  list;  the  "user  services"  notation  is  from  the 
reference  document.  The  direction  of  data  flow  is  "out"  from  the 
calling  procedure's  point  of  view.  The  "c&d_user_services_input" 
entry  name  (or  point)  must  be  declared  somewhere  in  an  appropri¬ 
ate  task  or  procedure. 

Before  revising  Listing  1  to  include  message  parameter 
detail,  a  convenient  form  of  grouping  related  information  is 
employed  that  enables  only  important  details  to  be  exhibited  at  a 
particular  place.  The  less  important  detailed  information  is 
placed  elsewhere.  Listing  4  shows  a  package  of  type  statements, 
each  type  declaration  is  a  record  definition  similar  to  that 
shown  in  Listing  3.  Details  of  the  variant  record  structure  are 
omitted. 

Listing  5  shows  a  redefinition  of  the  SPY-1  package  specifi¬ 
cation  shown  in  Listing  1.  Here  particular  procedure  headings  are 
defined  to  include  the  interfaces  in  both  directions.  This  allows 
messages  to  be  sent  in  either  direction  without  any  interdepen- 
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PACKAGE  inter face_types_package  IS 

TYPE  cid_interf ace_input  IS 

...  —  a  variant  record  structure 

TYPE  c&d_inter£ace_output  IS 
•  •  • 

TYPE  wcs_interface_input  IS 
•  •  • 

TYPE  wcs_interface_output  IS 

e  •  • 

TYPE  orts_inter£ace_input  IS 
•  •  « 

TYPE  orts_inter£ace_output  IS 
•  •  • 

TYPE  q£cs_interface_intput  IS 
•  •  • 

TYPE  gfcs_interface_output  IS 
•  •  • 

TYPE  atesinterfaceinput  IS 
•  •  • 

TYPE  ates_interface_output  IS 
•  •  • 

END  inter £ace_types  package; 

Listing  4.  A  package  o£  data  type  definitions, 
dence  upon  each  other.  These  ten  procedures  replace  the  five  pro¬ 
cedures  of  Listing  1.  A  corresponding  redefinition  of  the  pro¬ 
cedure  bodies  (which  are  enclosed  within  the  package  body)  would 
be  required.  Within  each  procedure  body  a  message  type  would  be 
determined  and  an  appropriate  entry  point  of  the  controlling  task 
called,  where  in  turn  other  appropriate  task  entry  points  may  be 
called,  thereby  forcing  appropriate  SPY-1  services  to  be  accom¬ 
plished. 

Again  the  private  type  definitions  are  omitted  because  they 
represent  internal  data  structures  not  needed  by  the  interface 
with  the  other  AEGIS  components.  Note  the  use  of  the  USE  state¬ 
ment  to  enable  the  bulky  definitions  to  he  placed  elsewhere  (in  a 
separate  package) . 
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PACKAGE  spy  1  IS 

USE  inter?ace_types_packagej 

PROCEDURE  c*d_user_services_input 

(m  s  IN  c&d_inter£ace_input) ; 

PROCEDURE  cfcd_user_services_output 

(m  s  OUT  c&d_interface_output) ; 

PROCUDURE  wcs_user_services_input 

(m  :  IN  wcs_interface_input) ; 

PROCEDURE  wcs_user_services_output 

(m  s  OUT  wcs_inter£ace_output) ; 

PROCEDURE  orts_user_services_input 

(m  ;  IN  orts_inter£ace_input) ; 

PROCEDURE  orts_user_services_output 

(m  :  OUT  or ts_inter £ace_output) ; 

PROCEDURE  gfcs_user_services_input 

(m  s  IN  gfcs_interface_input) ; 

PROCEDURE  g£cs_user_services_output 

(m  s  OUT  g£cs_inter £ace_output) ; 

PROCEDURE  ates_user_services_input 

(m  s  IN  atesinterface  input) ; 

PROCEDURE  ates_user_services_output 

(m  s  OUT  ates_inter£ace_output) ; 

PRIVATE 

—  declaration  of  private  data  types 
END  spy_l; 


Listing  5.  A  revision  of  Listing  1. 

We  now  address  the  internal  tasks  of  SPY-1.  Previously  a 
"spy_l_control"  task  was  defined  and  indicated  that  it  controlled 
and  coordinated  other  tasks  by  means  of  ACCEPT  statements  embed¬ 
ded  within  an  infinite  loop. 

Section  3. 3. 5. 2  of  the  reference  document  lists  the  various 
functions  performed  by  the  SPY-1  radar.  These  functions  are 
divided  into  two  groups:  a  "tactical  function  qroup"  and  an  "ele¬ 
ment  test  function  group".  These  are  shown  in  Tables  1  and  2, 
respectively. 

Listing  6  shows  a  skeleton  representation  of  a  SPY-1  func¬ 
tion  in  the  form  of  a  task.  Entry  points  (not  explicitly  shown) 
indicating  how  external  tasks  may  interact  with  the 
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Initialization 

Search  Management 

Track  Management 

Frequency  Management 

Radar  Scheduling 

Cross  Gating 

Beam  Stabilization 

Radar  Input  Processing 

Radar  Output  Processing 

Detection  Processing 

Track  Processing 

ECM/Clutter  Processing 

Track  Association 

Load  Evaluation 

Missile  Communications 

Historical  Recording 

Switch  Action  and  Display  Processing 

Video  Formatter 


Table  1.  SPY-1  Tactical  Functions. 

"search_management"  task  are  of  crucial  importance;  the  reference 
document  (or  at  least  the  unclassified  part)  does  not  indicate 
these  details.  Similar  tasks  would  be  defined  for  all  the  func¬ 
tions  listed  in  Tables  1  and  2. 

It  is  not  important  at  this  stage  of  modeling  to  know  the 
details  of  how  these  functions  work;  the  statement  of  what  must 
be  accomplished  is  of  higher  priority  at  the  early  design  stages. 
However  it  is  the  correct  interaction  of  these  functions  that  is 
the  next  highest  priority,  certainly  higher  priority  than  the 
details  of  their  algorithms.  For  this  reason  we  now  address  the 
Interaction  of  these  functions. 

The  ramification  of  modeling  the  interactions  is  the  defin¬ 
ition  in  the  ADA-like  notation  of  task  entry  points  that  can  be 
called  in  the  SELECT  statement  in  the  "spy-l-control”  task  of 
Listinq  2.  The  placement  of  the  calls  to  these  other  tasks  within 
the  various  select  clauses  describes  the  manner  of  interaction 
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EFT  Control 

Dynamic  Test  Targets 

Operability  and  Performance  Testing 

Angle  Calibration  Testing 

On-Line  Scan  Tests 

Transmitter  Power  and  Phase  Test 

Signal  Processor  Fault  Isolation  Support  Testing 

Nonmission  Tests 

Table  2.  SPY-1  Element  Test  Functions 
allowed,  and  the  parameter  lists  indicate  the  transfer  of  mes¬ 
sages  between  the  tasks.  Before  describing  the  SPY-1  radar  in 

i 

this  notation  a  review  of  the  ADA  notation  is  presented. 

Recall  that  tasks  execute  in  parallel  with  other  tasks,  and 
that  they  contain  explicit  entry  points,  and  that  each  entry 
point  can  optionally  have  a  parameter  list  that  affects  intertask 
communication.  From  within  a  particular  task  (or  procedure) 
another  task  may  be  invoked  or  called,  forcing  it  (the  calling 
task)  to  halt  execution  until  a  rendezvous  with  the  called  task 
can  legally  occur.  Meanwhile,  in  the  called  task,  execution  con¬ 
tinues  until  the  internal  logic  indicates  that  the  current  execu¬ 
tion  is  completed.  At  that  moment  the  calling  and  called  tasks 
can  legally  attempt  synchronization  and,  if  possible,  a  rendez¬ 
vous  is  said  to  occur.  The  SELECT  statement  in  the  called  task 
allows  the  rendezvous  to  happen  by  selecting  the  corresponding 
ACCEPT  statement  clause  to  be  executed;  the  select  mechanism  can 
force  the  calling  task  to  remain  halted  while  some  particular 
code  is  being  executed,  after  which  both  tasks  may  proceed  on 
their  independent  ways.  Possibly  some  additional  code  in  the 
coordinating  task  may  be  executed  prior  to  the  next  selection  by 
the  SELECT  statement.  The  continuing  selection  process  is 
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TASK  search_management  (...)  IS 

—  include  any  specification  details 

—  here  such  as  type  specifications, 

—  subprogram  specifications,  and 

—  entry  point  specifications. 

END; 

TASK  BODY  searchmanagement  IS 

—  local  declarations 
BEGIN 

—  a  select  statement  within  an  infinite 

—  loop  accepts  calls  to  this  task's  entry 

—  points,  which  when  undertaken  effect 

—  various  actions  on  part  of  the  SPY-1 

—  system. 

END; 


Listing  6.  A  representation  of  a  SPY-1  function, 
accomplished  because  (in  this  case)  the  SELECT  statement  is 
embedded  in  an  infinite  loop. 

The  reference  document  does  not  explicitly  indicate  the 
manner  in  which  the  various  functions  may  legally  interact, 
prohibiting  the  exact  representation  of  this  process  in  the  ADA- 
like  notation.  Figures  3.3. 5.3-3  through  3. 3. 5. 3-7  in  the  refer¬ 
ence  document  do  indicate  in  block  diagram  form  the  flow  of 
inter function  data  (messages)  among  the  various  functions.  At 
any  rate  the  exact  sequencing  among  the  functions  is  believed 
classified  and  so  would  not  be  accessible  to  this  study  in  any 
case. 

However,  since  this  part  of  the  system  model  is  so  vital  to 
the  correct  derivation  of  any  complex  system  (such  as  SPY-1)  and 
is  so  much  an  important  point  underlying  the  usefulness  of  the 
notation,  a  fictitious  characterization  of  the  interaction  is 
presented.  It  is  included  to  illustrate  how  the  notation  would 
appear,  and  is  not  to  be  construed  to  be  an  accurate  representa- 
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tion  of  how  the  SPY-1  radar  system  really  works.  Listing  7  indi¬ 
cates  how  the  various  functional  tasks  might  be  coordinated  by 
the  ADA-like  notation. 

—  appears  in  the  body  of  "spy_l_control"  task 
LOOP  —  an  infinite  loop  structure 

SELECT  —  this  statement  selects  among 

--  the  various  "accept"  statements, 

—  each  of  which  represents  a  task 

—  entry  point;  note  some  are 

—  are  "guarded"  by  a  "when"  statement 
ACCEPT  f requency_change_request  (...)  DO 

—  these  statements  are  executed  before 

—  the  rendezvoused  tasks  are  allowed 

—  to  proceed  independently 
END; 

—  these  statements  are  executed  before 

—  any  other  selection  of  a  rendezvous; 

—  typically  other  tasks  may  be  called 

—  upon  to  provide  some  kind  of  service. 

OR  ACCEPT  track_star trequest  (...)  DO 

• 

END; 


• 

OR  WHEN  dwelltimeexpired  ACCEPT 
next_beam_request  (...)  DO 

—  this  is  an  example  of  a  guarded 

—  rendezvous;  the  condition  must 

—  be  true  before  a  rendezvous  may 

—  occur 


•  •  • 

END; 

•  •  • 

—  other  guarded  or  unguarded  accept  statements 
END  SELECT; 

END  LOOP; 


Listing  7.  Fictitious  SPY-1  control  task  representation. 

Within  the  SELECT  statement  a  series  of  guarded  and  unguarded 
ACCEPT  statements  indicate  the  proper  coordination  and  data 
transfer  permitted  among  the  various  tasks.  Guarded  ACCEPT  state¬ 
ments  (having  the  WHEN  predicate)  permit  a  rendezvous  only  when 
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the  predicate  is  true.  In  general  all  tasks  are  executing  in 
parallel,  but  are  coordinated  by  the  "spy_l_control"  task  of 
which  Listing  7  is  but  a  part.  Because  the  SELECT  statement  is  in 
an  infinite  loop,  the  controlling  task  is  always  "checking"  for 
the  next  possible  rendezvous.  When  more  than  one  rendezvous  is 
possible  any  particular  one  is  selected  at  random.  If  no  rendez¬ 
vous  is  possible  (because  none  is  being  requested  or  guard  predi¬ 
cates  are  false)  the  controlling  task  just  waits.  Not  shown  in 
Listing  7  is  a  particular  ACCEPT  clause  that  would  allow  an  ORTS 
task  (or  procedure)  to  abort  or  kill  the  SPY-1  radar  system, 
effectively  causing  it  to  exit  the  infinite  loop  structure.  An 
alternative  notation  for  expressing  the  synchronization  of  tasks 
is  presented  in  [Andler79] ;  it  has  the  advantage  of  being  more 
succinct. 

ACCEPT  f requencychangerequest  (m  :  IN  c&dinterf aceinput)  DO 

saved_message  m; 

END;  —  calling  task  or  procedure  may  now  continue 

—  interpret  the  message  and  invoke  the  appropriate 

—  set  of  internal  tasks  such  that  the  request  is 

—  carried  out;  fictitious  tasks  are  illustrated  here 

CASE  saved_message . request  OP 

WHEN  phase_change  »> 

change_phase  (saved_message.rate) ;  —  task  invoked 
video_formatter  ("phase  changed");  —  to  operator 
WHEN  freq_change  *> 

change_f requency  (saved_messaqe .value) ; 
video_formatter  ("frequency  changed"); 

WHEN  . . . 

*  •  • 

END  CASE; 

—  this  is  the  end  of  the  accept  clause 

—  another  rendezvous  may  be  selected 


Listing  8.  Fictitious  detail  added  to  a  component  of 
Listing  7. 

A  further  fictitious  expansion  of  the  ACCEPT 


f requency_change_request  clause  portion  of  Listing  7  is  shown  in 
Listing  8.  Again  the  general  process  is  reviewed:  some  task 
external  to  the  SPY-1  environment  makes  a  request  for  a  SPY-1 
service  by  invoking  one  of  the  procedures  specified  in  the  SPY-1 
package  specification.  For  example  the  Command  and  Control  com¬ 
ponent  may  request  a  frequency  change  by  invoking  the 
"c&d_user_services_input"  procedure  with  an  appropriate  message 
argument.  Within  this  procedure  the  message  is  interpreted  and  an 
appropriate  SPY-1  internal  function  is  invoked  by  calling  an 
entry  point  in  the  spylcontrol  task,  whose  sole  purpose  is  to 
coordinate  all  such  requests.  When  the  spy_l_control  task  accepts 
the  call  (a  rendezvous)  the  message  is  saved  in  a  local  variable, 
and  then  the  calling  procedure  is  released  which  in  turn  can 
release  the  task  in  the  command  and  control  component  of  AEGIS. 
Meanwhile,  in  the  spylcontrol  task  the  accept  clause  is  con¬ 
tinuing  execution.  As  shown  is  Listing  8  the  particular  request 
may  be  determined  by  a  CASE  statement,  where  the  appropriate  WHEN 
clause  can  invoke  some  set  of  SPY-1  internal  tasks  (those 
corresponding  to  the  functions  listed  in  Tables  1  and  2) .  For 
example,  in  Listing  8,  if  the  " f r eqchange"  clause  is  executed 
two  (fictitious)  subtasks  of  the  Frequency  Management  function 
are  invoked,  presumably  adequate  for  carrying  out  the  requested 
service.  At  this  time  the  SELECT  statement  may  select  another 
pending  request  for  service. 

Even  though  the  reference  document  does  not  contain  enough 
unclassified  information  to  permit  the  representation  of  this 
controlling  task,  it  is  restated  again  that  it  is  precisely  this 


aspect  of  the  early  design  stages  that  is  among  the  most  essen¬ 
tial  to  a  successful  design  of  a  complex  interactive  system,  and 
that  the  advantage  of  the  ADA-like  notation  proposed  here  is  that 
it  allows  such  a  representation. 

VII  Summary  and  Conclusions 

This  research  study  derived  an  ADA-like  model  of  the  SPY-1 
radar  system  to  the  extent  budgetary,  reference  documents,  and 
security  constraints  permitted.  The  model  is  confined  to  the  very 
highest  level,  for  it  is  at  this  level  that  both  system  designers 
and  system  buyers  (customers)  must  mutually  understand  their  sys¬ 
tem  problems.  It  is  at  this  level  that  complex  system  designs 
usually  deviate  from  the  path  that  would  lead  directly  to  a  suc¬ 
cessful  system,  primarily  due  to  poor  specification  and  under¬ 
standing  of  the  buyer's  problem.  The  buyer  is  usually  not  in  the 
position  to  prohibit  the  deviation  because  they  are  not  (at  that 
time)  aware  of  it.  By  the  time  the  existence  of  the  deviation  is 
known  to  either  party,  much  time  and  effort  is  usually  wasted, 
and  additional  time  and  effort  is  expended  attempting  to  rectify 
the  inappropriately  designed  system. 

The  assertion  here  is  that  a  better  high  level  modeling 
technique  could  at  least  alleviate  the  problem,  by  forcing  the 
explicit  concentration  of  effort  on  the  proper  specification  of 
the  system's  high  level  design,  and  in  a  format  easily  under¬ 
standable  by  both  designers  and  the  customers.  An  ADA-like  nota¬ 
tion  is  proposed,  because  it  embodies  those  characteristics 
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important  to  specification  engineering,  is  (or  will  be)  a  nota¬ 
tion  familiar  to  both  designers  and  customers,  is  amenable  to 
machine  processing  to  ascertain  design  completeness  and  con¬ 
sistency,  and  will  be  used  (by  DoD  policy)  in  the  actual  codinq 
of  the  logic. 

Is  the  model  presented  here  for  the  SPY-1  radar  system  a 
convincing  argument  for  the  usefulness  of  the  notation?  The  goal 
of  this  research  is  not  to  definitively  answer  this  question,  but 
to  illustrate  the  proposition,  and  to  assess  the  utility  of  the 
technique  in  a  nonquantitative  manner.  It  is  suggested  here  that 
the  proposed  technique  does  satisfy  a  nonquantitative  assessment 
of  its  utility,  by  the  clarity  of  the  representation  of  SPY-1  as 
shown  in  the  previous  sections  and  again  in  the  appendix.  Only 
more  examples  of  the  method,  done  by  several  independent  study 
groups  and  over  a  period  of  time,  can  provide  data  so  that  the 
usefulness  of  the  technique  can  be  adequately  assessed.  It  is 
recommended  that  further  study  be  undertaken  for  this  purpose. 

A  further  qualifying  statement  must  be  made.  ADA  is  undergo¬ 
ing  (at  the  time  of  writing)  a  final  revision  of  its  definition, 
and  so  it  is  possible  (and  even  probable)  that  some  portions  of 
ADA  illustrated  here  may  not  remain  in  the  final  definition  of 
the  language.  This  is  one  more  reason  for  further  study  of  the 
usefulness  of  the  modeling  technique  proposed  here. 
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APPENDIX 


This  appendix  lists  the  final  form  of  the  ADA-like  model  of 
the  SPY-1  radar  system  developed  over  the  coarse  of  the  research. 
The  extent  of  the  model  is  limited  due  to  the  available  reference 
document  and  to  the  amount  of  manpower  used.  The  model  is  res¬ 
tated  here  to  bring  the  various  component  parts  of  the  SPY-1,  as 
presented  in  the  body  of  the  report,  into  one  place  where  a  qual¬ 
itative  assessment  as  to  its  usefulness  can  more  easily  be  made. 

Subordinate  packages  used  with  the  "spy_l"  package  are  placed 
at  the  end  of  this  appendix,  where  they  can  be  easily  referred 
to.  The  main  package  can  be  usefully  studied  with  only  occasional 
reference  to  the  subordinate  packages. 
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—  the  following  package  is  to  be  "used"  1 

—  in  an  encompassing  AEGIS  package  1 

PACKAGE  spy_l  IS  1 

—  the  following  package  contains  j 

—  type  definitions  for  all  messages  jj 

USE  interface_types_package;  . 

—  all  the  following  procedures  are  callable  from  J 

—  the  encompassing  AEGIS  package  and  effect  « 

—  all  SPY-1  services  to  AEGIS  \ 

PROCEDURE  c*d_user_services_input  j 

(m  :  IN  c&d_inter f ace_input) ;  | 

PROCEDURE  c&d_user_services_output  | 

(m  i  OUT  c&d_interface_output) ;  | 

PROCEDURE  wcs_user_services  input  | 

(m  :  IN  wcs_inter?ace_input) ;  I 

PROCEDURE  wcs_user_services_output  1 

(m  s  OUT  wcs_interface_output) ;  | 

PROCEDURE  orts_user_services  input 

(m  :  IN  orts_inter?ace_input) ; 

PROCEDURE  orts_user_services_output  | 

(m  :  OUT  orts_interface  output); 
procedure  gfcsuser  services_input 

(m  s  IN  g?cs_interface_input) ; 

PROCEDURE  gfcs_user_services_output 

(m  :  OUT  gfcs  interface  output)  ;  ] 

procedure  ates_user_services_input 

(m  s  IN  ates  interFace  input) ; 

PROCEDURE  ates_user_services_output 

(m  :  OUT  ates_inter face_output)  ; 

PRIVATE 

—  declaration  of  private  data  types 

—  probably  not  needed  in  this  package 

END  spy_l;  —  the  specification  part  j 
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PACKAGE  BODY  spy_l  IS 
—  all  local  declarations 

USE  interfunction__interfaces;  —  a  package 
PROCEDURE  BODY  c&d_user_services_input  IS 

—  all  local  declarations 
BEGIN 

—  interpret  the  message  and  invoke  appropriate 
—  SPYl  control  task  entry  points,  where 

—  appropriate  functional  tasks  will  be  invoked 

—  to  carry  out  the  request 
•  •  • 

•  •  * 

CASE  m.kind  OF 

WHEN  changejmode  *> 

—  request  rendezvous  with  spy_l_control 
track_start_request  — possfbly  with  argument 

WHEN  change_status  *> 


END  CASE; 

•  •  • 

END  c&d_user_services_input; 
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—  the  remaining  procedures  are  left  as 

—  separately  compiled  entities,  not  shown  in  appendix 
PROCEDURE  BODY  cid_user_services_output  IS  SEPARATE; 
PROCEDURE  BODY  wcs_user_services_input  IS  SEPARATE; 
PROCEDURE  BODY  wcs_user_services_output  IS  SEPARATE; 
PROCEDURE  BODY  or ts_user_services_input  IS  SEPARATE; 
PROCEDURE  BODY  orts_user_services_output  IS  SEPARATE; 
PROCEDURE  BODY  gfcs_user_services_ioput  IS  SEPARATE; 
PROCEDURE  BODY  gfcs_user_services_output  IS  SEPARATE; 
PROCEDURE  BODY  ates_user_services_input  IS  SEPARATE; 
PROCEDURE  BODY  ates_user_services_output  IS  SEPARATE; 


—  SPY-1  control  task  follows;  schedules  all 

—  requests  for  services  coming  via  the  above  procedures 
TASK  spy_l_control  IS 

—  entry  point  definitions  follow 

ENTRY  initialization_command  (ms  IN  ortsinterface  input) ; 
ENTRY  f requency_change_request  (...); 

ENTRY  track_start_request  (...); 

ENTRY  next_beam_request  (...); 

—  all  others  entry  declarations 

—  and  other  declarations 

END  spy_l_control;  —  the  specification  part 
TASK  BODY  spy_l_control  IS 
—  local  declarations 
BEGIN 

ACCEPT  initializationcommand (...); 

—  indirectly  From  ORTS  via 

—  orts_user_services_input  procedure 

—  actually  there  is  several  kinds 

—  of  initialization  commands  possible 

—  in  SPY-1,  but  are  not  indicated  here 
INITIATE  search_management ,  track_management , 

radar_scheduling ,  cross_gating , 
beamstabilization,  radarinput  processing, 
radar_output_processing ,  detectron_processing , 
trackprocessing,  ecm_clutter_processing , 
tr ack  assoc ia tion ,  load  evaluation , 
missile_communication,  histor ical_recordinq, 
switch  action_display_processing, 

video_Formatter ,  eft_control,  dynamic_test_tarqets, 
operabilityper formance_testing , 
anqle_cal i brat ion_tes ting ,  online_scan_tests, 
transmitter_power_phase  test, 

signal _processor_fault_Tsolation_suoport_testinq , 
nonmission_tests; 

—  and  whatever  subtasks  are  needed 


LOOP  —  an  "infinite"  loop  antarad 

SELECT  —  an  accapt  clausa  for  avary 
—  antry  point 

ACCEPT  f requencychangerequest 

(m  t  IN  c*d_inter£ace_input)  00 

savadmassaqa  : ■  m; 

END)  —  calling  procadura  may  continue 
--  interpret  the  massage  and  invoke 

—  the  appropriate  sat  of  internal 
--  tasks  such  that  the  request  is 

—  carried  out;  fictitious  tasks 

—  are  illustrated  hare 

CASE  savadmassaga. request  OF 
WHEN  phasechanga  ■> 

change  phase  (savadmassaga. rate) ; 
video_Formatter  ("phase  changed"); 

WHEN  freqchange  •> 

change  frequency  ( saved  message .value) 
video  formatter  ("frequency  chanqed"); 
WHEN 


• 

END  CASE; 

OR  ACCEPT  . 

OR  ACCEPT  . 

OR  WHEN  ....  ACCEPT 


a 

END  SELECT; 
END  LOOP; 


►l 
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—  remaining  tasks  are  left  as  separately 

—  compiled  units  not  shown  in  appendix 


TASK  search_management 
TASK  track_management 
TASK  f requency_management 
TASK  radar_scheduling 
TASK  crossgating 
TASK  beamstabilization 
TASK  radar_input_processing 
TASK  radar  output  processing 
TASK  detection_processing 
TASK  trackprocessing 
TASK  ecmclutter  processing 
TASK  track_assocTation 
TASK  load  evaluation 
TASK  missTle_communications 
TASK  histor icalrecord inq 
TASK  switch_action  display  processing 
TASK  video  formatter 
TASK  eft  control 
TASK  dynamictest  targets 
TASK  operability  performance  testing 
TASK  angle  cal ibrat ion  testing 
TASK  online  scan  tests 
TASK  transmTtter^powera _phase_test 
TASK  s ignal  processor  fault  isolation  support  test ing 

IS  SEPARATE; 

TASK  nonmission  tests  IS  SEPARATE; 

—  and  whatever  subtasks  are  necessary 


IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
IS  SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 


IS 

IS 

IS 

IS 

IS 

IS 


BEGIN 

INITIATE 
END  spy  1; 


initialization  part  of  packaqe 
spyl  control ; 

end  of  complete  SPY-1  packaqe 


—  the  interface  message  type  package 

—  all  the  following  is  from  the  reference 

—  document;  detailed  to  the  extent  given  there 

—  in  some  cases  the  detail  varys  slightly 

—  from  the  assumptions  used  in  the  model 


PACKAGE  interf ace_types_package  IS 

TYPE  c&d_interface_input  IS 
RECORD 

kind  s  (track  data,  data_ack,  burnthrough_rpt , 
track_acc_rey,  radar_status ,  burnthrough_acc_re j , 
redundant_track ,  radar_load_status ,  rscstatus, 
radar  doctrine); 

CASE  kTnd  OP  —  question  marks  indicate  unknown  types 
WHEN  track_c?ata  *> 
nooftracks  s  ???; 
ctsl  s  ???; 

control_grp_trk  no  s  ???; 
weaponcontrollndexes  :  ???; 
time  lag  t  ???; 
amplitude  estimates  :  ???; 
parentctsl  :  ???; 

typetrackindicators  :  (real,  simulated); 
position  s  ARRAY  (coordinates)  OP  REAL; 
velocity  :  ARRAY  (coordinates)  OF  REAL; 
slantrange  :  ???; 
slantrange  rate  :  ???; 
lost  tracklndicator  s  ???; 
bearing  data  s  ???; 
elevationdata  ;  ???; 
track_coast_count  x  ???; 
track_indicators  ;  (old,  new); 
trackmodeindicators  ;  (active,  passive, 
coverpulse,  missile); 
missileindicator  x  ???; 
reporttype  x  (normal,  specialthreat) ; 

WHEN  data  ack  ■> 
ctsl  x  ???; 

control  gprtrkno  :  ???; 

rang*  rate  x  ???; 

status  x  (enable,  disable); 

minbearing,  maxbearing  :  ???; 
minrange,  maxrange  x  ???; 


**v toSfe 
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WHEN  burnthrough_rpt  => 

console_address  :  ???; 
ctsl  :  ???; 

control_grp_trk_ no  :  ???; 
time_tag  s  ???> 
elevation  s  ???; 
bearing  :  ???; 

target_ranges  s  ARRAY  (nooftargets)  OF  REAL; 
WHEN  track_acc_re j  *> 
ctsl  :  ???; 

responsecode  s  (accept,  busy,  illeqal); 

WHEN  rsc  status  =*> 

controlgrpstatus  :  (start_up,  ready); 
radarstatus  :  (fore_off,  forestandby, 
fore  ready,  f ore_radiate ,  aft_off, 
a£t_standby,  aft_ready,  af t_rad iate) ; 

WHEN  burnthrouqh_acc_re j  *> 
cid  trk  index  :  ???; 
control_grp_trk_no  :  ???; 
response_code  :  (accept,  busy,  illegal); 

WHEN  redundanttrack  *> 
ctsl  :  ???; 

control_grp_trk_no  :  ???; 

WHEN  radar  load_status  *> 

trk_fTlepercent_load  :  ???; 
radar  percentload  ;  ???; 
contr ol_grp_percent_load  :  ???; 
time_taq  :  ???; 
search  frame_time  :  ???; 
radar  status  :  ???; 
percenttracktime  :  ??? 

WHEN  rsc  status  *> 

consoleaddress  :  ???; 
typereply  :  (good,  bad,  missed); 

WHEN  radar_doctr ine  *> 

—  AN/SPY-1  doctrine  (not  given) 

END  CASE; 

END  RECORD; 
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TYPE  c&d_interf ace_output  IS 
RECORD 

kind  :  (track_id,  auto_ mode_parameters , 
cease_rpt_drop_trk ,  trk_acquisition_req, 
shipsspeed,  burnthrough_req,  display_req, 
c&d_doctr inecontrol f  passive_trk_data , 
alert_pending) ; 

CASE  kind  OF 

WHEN  track_id  «> 
ctsl  s  ???; 

weapon_control_index  :  ???; 
radar_set_trk_no  :  ???; 
category  :  (air,  surface,  clutter); 
id_class  :  (conf irmed_hostile , 

assumed_hosti le ,  unknown,  assumed  friendly, 
confirmed  friendly,  controlled_f rTendly) ; 
tactically_sTgnif icant  :  ???; 

WHEN  auto_mode_parameters  *> 
min_range_rate  :  ???j 

ending_bear ing ,  starting_bear ing  t  ???> 
minrange,  maxrange  :  ???; 
status  :  (enable,  disable); 

WHEN  cease_rpt_drop_trk  ■> 
ctsl  s  ???; 

controlgrptrkno  s  ???; 
weaponcontrol  index  :  ???; 
drop_trk_indicator  j  ???; 

WHEN  trackacquisition  req  *> 
time_taq  :  ???; 

dimensional  indicator  ;  (two  d,  three_d) ; 
position  ;  ARRAY  (coordinates)  OF  REAL; 
velocity  s  ARRAY  (coordinates)  OF  REAL; 
ctsl  :  ???; 

weapon  control_index  ;  ???; 
acquisTtionindicator  :  (active,  passive, 
surface) ; 

asimuth_extent  ;  (normal,  wide); 

WHEN  ships__speed  »> 
x__dot,  y_dot  :  ???; 
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WHEN  burnthrough_req  => 
ct si  :  ???; 

control_grp_trk_no  :  ???; 
request_type  :  (high_vel,  low_vel); 
start_range  :  ???; 

WHEN  display_req  => 

console_address  :  ???; 
video_formatter_type  :  ???; 
header_code  :  ???; 

display_mode  :  (above_horiz ,  horizclear, 
horiz_mti); 

WHEN  c&d_doctr ine_control  => 
radarsilence  :  (on,  off); 

WHEN  passi ve_trk_range_data  => 
ctsl  :  ???; 
radar_trk_no  :  ???; 
range  :  ???; 
range_rate  :  ???; 
time_tags  :  ???; 
data_source_id  :  ???; 
weapon_control_index  :  ???; 
associated_patl  :  ???; 
coast_count  :  ???; 

WHEN  alert_pending  => 

—  notice  of  alert 
END  CASE; 

END  RECORD; 
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PACKAGE  interf unction_interf aces  IS 

—  these  are  typical  of  the  data  structures 

—  used  for  internal  SPY-1  function  communication, 

—  and  are  included  here  for  illustrative  purposes 
TYPE  initiali2ation_interf ace_input  IS 

RECORD 

kind  j  (initialization_orders,  test_results_summary , 
radar_status_summary,  gryo_sta tus_summary , 
ates_initial_complete ,  transmitter_status , 
loop_closure_conf irmation) ; 

CASE  kind  OP 

WHEN  initialization_orders  => 

—  initialization  switch  actions 

—  details  not  known 
WHEN  test_results_summary  => 

—  results  of  CAL,  OPT,  OLS 
WHEN  radar_status_summary  => 

—  summary  of  radar  operable  units 
WHEN  gyro_status_data  -> 

—  gyro  data  converter  and  gyro  status  data 
WHEN  ates_initial_complete  => 

—  indication  that  radar  initialization 

—  can  commence 

WHEN  transmitterstatus  => 

—  transmitter,  status,  i.  e.,  standby 

—  ready,  (requested  and  received) 

WHEN  loop_closure_conf irmation  => 

—  notification  of  first  radar  return 
END  CASE; 

END  RECORD; 

TYPE  initialization_interface_output  IS 
RECORD 

kind  j  (xmtr_state,  etf_test_requests , 

request_start_gyro ,  radar_system_status) ; 

—  next  page  classified,  more  may  follow 
CASE  kind  OF 

WHEN  xmtrstate  *> 

—  command  to  change  xmtr  state  up  or  down 
WHEN  etf_test_requests  => 

~  none  given  in  reference  source 
WHEN  request_start_gyro  => 

—  request  to  start  gyro  module 
WHEN  radar_system_status  => 

~  control  group  status/radar  system  status 

—  dedicated  etf-test  flag  or  normal  etf- 

—  test  priority 
END  CASE; 

END  RECORD; 


TYPE  £ requencymanagementinput  IS 
RECORD 

kind  :  (beamposi tion ,  targetinformation, 
doctrine,  hardware_operability, 
missile_in£ormation> ; 

CASE  kind  OP  —  question  marks  mean  unkown  type 
WHEN  beamposi tion  => 
bearing  :  ???; 
elevation  :  ???; 
sector  :  ???; 
subsector  :  ???; 

WHEN  target  information  => 
range_rate  :  ???; 
mode  :  ???; 
mti_pr i_index  :  ???; 

WHEN  doctrine  => 

—  frequency  doctrine 
fixed  s  ???; 
prelook  :  ???; 
random  :  ???; 

—  sector  doctrine 
minmaxbear ing  :  ???; 
excluded! requency  channels  :  ???; 

—  baseline  doctrine 
excluded^ requencychannels  :  ???; 

WHEN  hardware_operability  => 

—  frequency  constrained  by  hardware 
WHEN  missi leinformation  => 

uplink  freq,  downl ink_f req  s  ???; 

END  CASE; 

END  RECORD; 
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TYPE  radar_scheduling_input  IS 
RECORD 

kind  :  (search_lists_special ,  radiation_doctr ine 
time_sych,  track_beam_scheduled , 
ships_motion_matr ix ,  radar_silence , 
wave£orm_information,  mode_status , 
xtmr_state,  track_time_counter_reset) ; 

CASE  kind  OP 

WHEN  search_lists_special  => 

—  HS  and  AHS  and  special  requests 
stc_data  :  ???; 
beam_posi tion  :  ???; 
blanking_gates  s  ???; 
clutter_gates  :  ???; 
mode  j  ???; 

instrumented_range  :  ??? j 
clutter_map_f lag  :  ???; 
endof  frame_flag  :  ???; 

WHEN  radTation_doctr ine  *> 

—  relative  bearings  of  radiation 

—  inhibit  sectors 
power_option  s  (high,  low,  off); 

WHEN  time__sync  => 

—  resynchronization  time 
WHEN  track_beam_scheduled  => 

—  track  numbers  by  priority 

—  track  file 

WHEN  ships_motion_matr ix  *> 

—  stable  deck  orientation 

—  azimuth  limits  for  search  &  track 

—  azimuth  limit  slope 
WHEN  radar_silence  => 

—  radiation  inhibit 

WHEN  wave£orm_information  => 

—  frequency  channel  and  bands 

—  phase  code  pri  and  dwell  time  for  mti 
WHEN  mode_status  =»> 

—  waveform  substitution 
WHEN  xmtr_state  => 

—  xmtr  state 

WHEN  track_time_counter_reset  => 

—  reset  for  track  time  counter 
END  CASE; 

END  RECORD; 

—  all  the  remaining  inter  function  interfaces 
END  interfunction  interfaces; 
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